I've had many-a conversations with engineers on the pros and cons of monorepos vs. alternatives (microservices, bi-repo backend and frontend, etc.)

Some unorganized thoughts on building engineering/product teams on the pros/cons here:

• Full-stack engineers severely limits the costs of multiple language-repos (e.g. python backend, TS frontend)
• Most engineers are not fully aware of the additional coordination costs entailed with dual-repo, dual-language structures
• Only a technical coordinator lead can really assess the technical cost added with the coordination costs increase
• The coordination costs comes ENTIRELY from ANY time spent talking where people talk about who does what, and which logics sits where
• It is easier to take a competent, smart engineer who knows frontend well (namely gritted their teeth through CSS and JS) learn backend engineering (to be full-stack) than the other way around
• However backend engineers like ones focused on Python/Go/etc. can almost certainly learn TS and manage all the CRUD, state management, and API calls from the TS side (if you have a TS frontend and Python backend)
• While it's clear where 95% of the logic will sit in a bi-repo structure, 5% of the logic will be unclear a priori; these are often nuanced things like (filtering, sorting data can be done on the frontend or backend)
• If you want to do optimistic updates (zippy frontend reactions), it takes more thinking about how to exactly render and update data models
• As a product or technical lead, you should be able to taste MEAT cost (money, energy, attention, time)
• You should ruthlessly, absolutely destroy all wasteful inefficiencies surrounding meat cost around coordination
• An excellently run, high product velocity engineer-prod culture should look almost ENTIRELY of MAKER TIME
• If engineers are asking questions around: "What are we doing. Who is doing what, Why are we doing that, How we are doing that?"
• Strategy, tactics, architecture, and coordination have not been sufficiently communicated effectively
• Back and forths between frontend and backend for things like filtering and sorting data (on frontend or backend) are a pain in the ass for coordination back and forth
• It's better for an eng to understand both sides and decide where the logic sits on either side And how they talk to each other
• The above reflects in internal psychology and communication as well
• Back and forths within an engineer's mind about what are valuable things to build, are extremely costly
• Think in terms of the highest efficiency point the hand off the baton (Baton Handoff)
• It's way easier to handoff the baton from a working CRUD prototype on frontend with API calls all hooked in requiring just "polish UI" - rather than to handoff a baton from engA to engB with completed API calls
• So why monorepo ...?
• Likely monorepo is more efficient
  • You don't need to worry about multiple languages, instead likely all TS
  • Engineers don't need to think about where logic sits and in which language
• One of the core benefits of a Bi-Repo structure in specifically remote teams is gradual introduction of new remote engineers as trust is built (like a 1/2 multi-sig initially and then 2/2).
• Codebases require investment of engineering time and money therefore entail Value at Risk (VAR)